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(54) Method and system for secure distribution of cryptographic keys on multicast networks 



(57) A method and apparatus for secure and scala- 
ble key management in a multicast network environ- 
ment is provided. In a first portion, one or more seed 
nodes on the network receive a multicast transmission 
request for a cryptographic key from a requesting node. 
The seed node compares the identity of the requesting 
node with an authenticated predetermined list of nodes 
having permission to receive the cryptographic key If 
the comparison indicates the requesting node is not a 
member of the authenticated predetermined list, the 
seed node denies the multicast request. However, if the 
comparison indicates that the requesting node is a 
member of the predetermined list of nodes, the crypto- 
graphic key is transmitted using a secure unicast key 
distribution technique such as SKIP. A second portion 
concerns the requesting node which generates a multi- 
cast request to obtain the cryptographic key from one 



or more seed nodes and one or more keyed nodes on 
the internetwork. The multicast request for the crypto- 
graphic key is initially transmitted a minimum hop count 
over the internetwork to locate the closest seed node. 
The requesting node delays a brief time period waiting 
for at least one response from at least one seed node 
or keyed node on the internetwork. If the at least one 
response is not received within this time period, the min- 
imum hop count is increased by a hop count increment 
and the requesting node repeats the above steps. Even- 
tually, the requesting node increases the hop count and 
receives the cryptographic key over a secure unicast 
key management technique such as SKIP. As a final 
step, the requesting node is convered intoa keyed node. 
The keyed node acts as a seed node and provides the 
cryptographic key to other requesting nodes on the in- 
ternetwork. 
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Description 

Field of the Invention 

The present invention relates generally to computer 
cryptography and, more specifically, to a method and 
system for secure distribution of cryptographic keys on 
multicast networks. 

Background Of The Invention 

Network computing has grown at a phenomenal 
rate over the last decade. In a network computing envi- 
ronment, a user has access to the computing power of 
multiple computers located on a network. Sun Microsys- 
tems Inc., a leader in network computing, even devised 
a marketing campaign around the slogan The Network 
/sthe Computer"™ to emphasize the commercial suc- 
cess of this growing segment of the computing market 1 . 
Recently, this slogan has become reality as millions of 
users have tapped the computing resources available 
from the thousands of computers available on the Inter- 
net and the World Wide Web. 

One of the more interesting areas of research in net- 
work computing concerns how to simultaneously and ef- 
ficiently transmit information to multiple nodes on a net- 
work. In particular, many people are researching multi- 
cast protocols. A multicast protocol allows a transmitter 
node on a network to send the same data packets to 
multiple specific receiver nodes on a network without us- 
ing separate point-to-point connections. The point-to- 
point connections, also referred to as unicast connec- 
tions, are not desireable because each point-to-point 
connection establishes a seperate logical network con- 
nection between the transmitter node and each receiver 
node on the network. The seperate logical network con- 
nection requires seperate network resources, such as 
a seperate IP (Internet Protocol) connection, to estab- 
lish the actual connection as well as additional band- 
width to transmit multiple copies of the same packet. 
This wastes network resources because the information 
being transmitted over each network connection is iden- 
tical. 

The multicast protocol enables the transmitting 
node to transmit a series of data packets to multiple re- 
ceivers without establishing a seperate network connec- 
tion for each receiver node or sending duplicate packets 
of the data over a network. Instead, the multicast proto- 
col sends a single stream of packets over the network 
in which only members of the multicast group are able 
to read. Multicast is an improvement over unicast pro- 

1 . The Network Is the Computer. Sun., the Sun logo, Sun Microsystems, 
Solaris. Ultra and Java are trademarks or registered trademarks of Sun 
Microsystems, Inc. in the United States and in other countries. All 
SPARC trademarks are used under license and are trademarks or reg- 
istered trademarks of SPARC International Inc. in the United States and 
other countries. Products bearing SPARC trademarks are based upon 
an architecture developed by Sun Microsystems, Inc. UNIX is a regis- 
tered trademark in the United Stales and other countries exclusively li- 
censed through X/Open Company, Ltd. 



tocols using numerous point-to-point channels because 
multicast does not send redundant packets of informa- 
tion. Multicast is also advantageous because only a pre- 
determined list of multicast members can receive the 

5 multicast transmission. 

An increasing number of practical applications 
available on the Internet such as live stock quotes, video 
conferencing, white board applications, electronic com- 
merce, remote learning, and other group communica- 

fo tions are migrating to multicast protocols to resolve 
these network bandwidth deficiencies. These applica- 
tions will invariably contain sensitive and confidential in- 
formation about their users. Consequently, packets 
transmitted over these multicast networks should be en- 
crypted to prevent eavesdropping by individuals not in 
the multicast group. 

Accordingly, there are at least two general concerns 
in designing robust cryptographic systems for encrypt- 
ing information distributed on a multicast network: en- 

20 cryption and key management. First, the encryption 
technique used to encrypt the information must not be 
easily compromised by an unauthorized eavesdropper. 
To evade such eavesdroppers, algorithms such as Data 
Encryption Standard (DES) are used to to encrypt data 

2S using a cryptographic key. The protection against hack- 
ers and interlopers lies in the length of the cryptographic 
key in addition to the complexity of the encryption algo- 
rithm. Generally, a longer cryptographic key requires 
more computer resources and more time to decrypt. 

30 Thus, by changing the cryptographic keys at regular 
time intervals, hackers will not have sufficient time to 
compute the cryptographic keys. 

The second, and often more difficult, aspect of cryp- 
tographic systems lies in the key management. Key 

35 management typically involves secure key distribution 
and scalability. Essentially, key distribution must be se- 
cure or a hacker will obtain the key and security will be 
compromised. Moreover, in a large multicast network 
the key distribution must scale well so that a large 

40 number of users can obtain the keys quickly and effi- 
ciently. The size of the multicast group and request for 
keys should not degrade performance of the crypto- 
graphic system. Establishing management techniques 
which scale well for large multicast groups has remained 

45 a problem in cryptographic systems. 

Typically, modern cryptographic systems use key 
management to manage distribution of a traffic key and 
a key encrypting key. The traffic key is a key used to 
actually encrypt the data being transmitted across a net- 

50 work while the key encrypting key is a key used to en- 
crypt the traffic key and prevent it from being discovered 
en route to a receiving node. Both of these keys must be 
distributed in a manner which scales to multicast net- 
works with a large number of multicast members. 

55 Unfortunately, existing key management tech- 

niques often use a single server, sometimes referred to 
as a Group Coordinator or GC, to distribute the traffic 
keys or key encrypting keys associated with a multicast 
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transmission. The GC maintains secure key distribution 
but can be overwhelmed if the requests are too frequent 
and too numerous. In some cases, requesting nodes ge- 
ographically distant from the single server will experi- 
ence delays in receiving a key and can miss part, if not 
all, of a multicast transmission in the interim. In a worst 
case : a large mullicast group can suddenly overload the 
GC with requests such that certain members of the mul- 
ticast group never receive any keys. Members of the 
multicast group without the appropiate keys would be 
excluded from the multicast transmission entirely. Key 
management techniques must be improved to scale 
with large multicast groups. 

A multicast extension using the SKIP 1 (Simple Key 
Management for Internet Protocols) protocol scales well 
for distributing the Iraltic key but does not scale as well 
for distributing the key encrypting key. In multicast SKIP, 
the traffic key is used to encrypt data in a packet. The 
traffic key is an inline traffic key because it is included 
with each packet To keep the traffic key confidential, 
SKIP for multicast IP (Internet Protocol) encrypts the 
traffic key using a key encrypting key referred to as a 
Group Interchange Key or GIK. 

Distribution of the traffic key in multicast SKIP 
scales well to large multicast groups because each 
member of the multicast group receiving a packet has 
a copy of the traffic key. However, the distribution of the 
GIK does not scale as easily. Unlike the inline traffic key, 
SKIP uses public-key key distribution to distribute the 
GIK with 1 a single server known as the Group Controller 
or GC.-When membership in the multicast group gets 
too large and geographically spread out, the GC can 
have difficulty distributing the GIK. Thus, while traffic key 
distribution using an inline traffic key is highly scalable, 
the distribution of the GIK from a single GC remains only 
moderately scalable. Details on multicast SKIP are in- 
cluded in the paper entitled "Design and Implementation 
of SKIP", authored by Ashar Aziz and Martin Patterson, 
June 28, 1 995. 

Other existing key-management techniques which 
have not addressed scalable key distribution techniques 
also suffer problems similar to the ones discussed 
above. One technique called Group Key Management 
Protocol (GKMP 1 ) contemplates that the GIK (referred 
to in GKMP as a "traffic key") can be distributed by in- 
dividual members of a multicast group but does not in- 
dicate an efficient and secure technique for selecting 
members of the mullicast group to distribute the key en- 
crypting key. Further, GKMP does not discuss a secure 
means in which key requests for the GIK are fulfilled. 
Essentially, the GKMP technique can still overload a 
group owner or group coordinator with key requests be- 
cause the load associated with fulfilling those key re- 
quests is not necessarily distributed evenly over multiple 

1 .SotsticefTM) PC-SKIP(TM) SunScreen(TM) SKIP are trademarks of 
Sun Microsystems. Inc. 

1.IETF Internet-Draft Group Key Management Protocol Architecture. 
Hugh Harney and Carl Muckenhirn. SPARTA. Inc. June 18. 1996 



servers. 

Anothertechniquediscussed in RFC 194g address- 
es multicast key distribution in the context of a specific 
multicast routing protocol using Core Based Trees 

5 (CBT). This scheme has the drawback of tying the key 
distribution to a specific multicast routing protocol, 
namely CBT. Moreover, it also suffers from the problem 
of having to involve and trust entities whose role is de- 
termined by virtue of the multicast routing protocol. Un- 

io fortunately, the CBT multicast routing protocol deter- 
mines the efficiency of transmitting multicast data based 
on a particular route and not based on which nodes on 
the network are to be trusted as a secure node for dis- 
tributing a key. 

is What is needed is a technique for managing keys 
on a secure network which scales based on the load 
and geographic location of a rapidly growing multicast 
group. This technique should not compromise the level 
of security during transmission or reduce either forward 

20 or reverse secrecy. 

Summary Of The Invention 

Embodiments of the present invention provide a 

25 method and apparatus for secu re and scalable key man- 
agement in a multicast network environment. One em- 
bodiment of the present invention securely distributes a 
multicast cryptographic key, initially located on one or 
more seed nodes, to a requesting node. In one multicast 

30 environment the multicast cryptographic key is a key en- 
crypting key called a group interchange key (GIK) and 
is used to encrypt a multicast traffic key. Accordingly, 
the seed nodes in this one embodiment are one or more 
nodes on the network which initially hold the GIK and 

35 are capable of securely distributing the GIK in accord- 
ance with principles of the present invention. Generally, 
seed nodes are distributed in the network so they are 
geographically close to the concentration of requesting 
nodes in the network. 

40 Initially, one or more seed nodes on the network re- 
ceives a multicast transmission request for the multicast 
cryptographic key from a requesting node. The multicast 
request is neither encrypted nor authenticated and 
therefore is insecure. Typically, the seed node closest 

45 to the requesting node receives the request first and re- 
sponds. The closest seed node determines if the re- 
questing node making the multicast request has permis- 
sion to receive the multicast cryptographic key by per- 
forming several steps. First, the seed node compares 

50 the identity of the requesting node with an authenticated 
list of nodes having permission to receive the multicast 
cryptographic key. If the comparison indicates the re- 
questing node is not a member of the authenticated pre- 
determined list of nodes having permission to receive 

55 the multicast cryptographic key, the seed node denies 
the multicast request. However, if the comparing step 
indicates the requesting node is a member of the pre- 
determined list of nodes having permission to receive 
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the multicast cryptographic key, the multicast crypto- 
graphic key is transmitted using a secure unicast key 
distribution technique such as unicast SKIP 

Unlike existing key management techniques, a re- 
questing node can request a multicast cryptographic s 
key from a number of different seed nodes on the net- 
work. This technique off loads the processing from a sin- 
gle seed node or group controller (GC) because any 
one of the seed nodes on the network can distribute the 
multicast cryptographic key. 10 

This technique is also advantageous because an 
insecure multicast request requires less processing on 
the part of the seed node than a secure multicast re- 
quest which is encrypted and authenticated. Despite us- 
ing an insecure request, a multicast key distribution is 
technique implemented in accordance with principles of 
the present invention remains secure because the seed 
node distributes a multicast cyptographic key using a 
secure unicast key management technique such as uni- 
cast SKIP. 20 

A second embodiment of the present invention ex- 
ecuted on the requesting node enables the requesting 
node to obtain a multicast cryptographic key from the 
seed node closest to the requesting node on the inter- 
network using an expanding ring of requests. Further, 25 
once the requesting node receives the multicast cryto- 
graphic key, the second embodiment converts the re- 
questing node into a keyed node which can then distrib- 
ute the multicast cryptographic key to subsequent re- 
questing nodes in the multicast group. Unlike the seed 30 
node, the keyed node initially does not have a copy of 
the multicast cryptographic key and can not distribute 
the multicast cryptographic key until the requesting 
node's request for the multicast cryptographic key is 
successfully filled. 3S 

In accordance with the second embodiment, the re- 
questing node generates a multicast request to obtain 
the multicast cryptographic key from one or more seed 
nodes and one or more keyed nodes on the internet- 
work. The multicast request for the multicast crypto- 40 
graphic key is initially transmitted a minimum hop count 
over the internetwork to locate the closest seed node. 
The hop count provides an upper limit on the number of 
networks the request will traverse to locate a seed node. 
The requesting node delays a brief time period waiting *s 
for at least one response from at least one seed node 
or keyed node on the internetwork. If the at least one 
response is not received within this time period, the min- 
imum hop count is increased by a hop count increment 
and the requesting node repeats the requesting process so 
above. By increasing the hop count over time, an ex- 
panding ring of multicast key requests increases the 
likelihood of locating a seed node with the multicast 
cryptographic key while minimizing the amount of net- 
work traffic. Eventually, the requesting node increases 
the hop count and receives the multicast cryptographic 
key using a secure unicast key management technique 
such as unicast SKIP. As a final step, the requesting 



node is converted into a keyed node which provides the 
multicast cryptographic key to other requesting nodes 
on the internetwork. 

Embodiments of the invention offer several advan- 
tages in the area of key management for use in encryp- 
tion systems which were previously unavailable in the 
art. Unlike existing techniques, this key management 
system scales well in a large multicasting networks with 
members spread out over a large geographic distance. 
In the past, a single group coordinator (GC) would be- 
come quickly overwhelmed if all the members in a mul- 
ticast group requested an encryption key in a short time 
interval. For example, the multicast SKIP protocol used 
a single GC to distribute the multicast cryptographic key, 
called the group interchange key (Gl K), to each member 
of the multicast group who wanted to receive multicast 
transmissions. This worked well for small multicast 
groups but did not scale well for larger multicast groups. 
By enhanching SKIP with teachings of the present in- 
vention, the processing associated with distributing the 
key is spread out to multiple seed nodes and keyed 
nodes on the internetwork. This technique minimizes 
the demand on a central GC because members of the 
multicast group can request a GIK from the nearest 
keyed node or seed node rather than one centrally lo- 
cated GC. The expanding ring of multicast requests fur- 
ther exploits the availability of cryptographic keys on 
multiple seed nodes and keyed nodes on a network by 
making requests for the multicast cryptographic key 
from the closest seed nodes and keyed nodes. 

The techniques used by the present invention are 
also beneficial because they balance the processing 
load associated with key distribution based on the geo- 
graphic location of key requests. Each additional cryp- 
tographic key request establishes a keyed node which 
can distribute the cryptographic key to other nearby 
nodes on the internetwork. Using multiple seed nodes 
and keyed nodes to distribute the multicast cryptograph- 
ic key distributes the processing load to many different 
nodes rather than one group controlloer or GC. 

Further, requesting a cryptographic key using an 
expanding ring locates nearby seed nodes or keyed 
nodes rather than a distant node on the network. This 
minimizes network traffic and makes key distribution 
fast and efficient. Consequently, members in a large 
multicast group will experience consistent key distribu- 
tion performance when requesting cryptographic keys 
even if ihey are located in different geographic locations. 



Brief Description Of The Drawings 

Embodiments of the present invention are illustrat- 
ed by way of example, and not by way of limitation, in 
the figures of the accompanying drawings and in which 
like reference numerals refer to similar elements and in 
which: 
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FIG. 1 illustrates a computer network for practicing 
one key-management technique for cryptogrpahic 
systems in accordance with the present invention. 
FIG. 2 is a flow chart indicating the overall steps 
used in accordance with one embodiment of the 
present invention to distribute a multicast crypto- 
graphic key to a requesting node from either a seed 
node or a keyed node ; 

FIG. 3 is a flow chart outlining the overall steps used 
by one embodiment of the present invention to ob- 
tain a multicast cryptographic key; and 
FIG. 4 illustrates one embodiment of an encrypted 
unicast packet generated for securely transmitting 
a GIK. 

Detailed Description 

Environment/Preconditions 

FIG. 1 illustrates a computer network 100 for prac- 
ticing a key-management technique for cryptographic 
systems in accordance with the present invention. Gen- 
erally, embodiments of the present invention are de- 
signed to be implemented in an internetwork which re- 
quire a key-management technique for the securely dis- 
tributing cryptographic keys for multicast transmissions. 
As will be apparent from the discussion below, embod- 
iments of the present invention exhibit exceptional scal- 
ability in Marge key-management scenarios by strategi- 
cally distributing the associated processing load. For ex- 
ample, ;th is key-management technique is particularly 
useful insecure multicast transmissions where the cryp- 
tographic key must be distributed to a large multicast 
group having members spread out over a large geo- 
graphic-area. 

Referring to FIG. 1 , computer network 100 includes 
server computers 102 and 104 configured to communi- 
cate with a client computer 106 over a network 110. 

Server 1 02 includes a network interface 1 1 2, a proc- 
essor 114, a primary storage 116, a secondary storage 
118, and an I/O (input output) interface 120 which facil- 
itates communication between these aforementioned 
elements. Network interface 112 couples server 102 to 
network 110 and facilitates two-way data communica- 
tion between server computer 102 and other computers 
on the network 110. For example, if network interface 
1 1 2 is an integrated services digital network (ISDN) card 
or a modem, network interface 112 provides a physical 
connection to the corresponding type of telephone line. 
If network interface 112 is a local area network card 
(LAN) card, network interface 112 provides a physical 
connection to a compatible LAN. Wireless links are also 
possible. Preferably, the client and server computers 
coupled to this network transmit information utilizing the 
TCP/IP protocol. Other network protocols such as SNA, 
X.25, Novell Netware 1 , Vines, or AppleTalk could also 

1 . Netware is a registered trademark of Novell, Inc. in the United States 
and other countries. 



be used to provide similar client-server communication 
capabilities. In any such implementation, network inter- 
face 112 sends and receives electrical, electromagnetic, 
or optical signals which carry digital data streams rep- 
5 resenting various types of information. 

Network 1 1 0 typically provides data communication 
through one or more networks to other data devices. For 
example, network 1 1 0 can provide a network connection 
between server 1 02 and client 1 06, in part, using a world 
wide packet data communication network now com- 
monly referred to as the "Internet'. The Internet uses 
electrical, electromagnetic, or optical signals to carry 
digital data streams representing various types of infor- 
mation. The signals carried through network 110 and 
through network interface 112, which carry the digital 
data to and from server 1 02, are exemplary forms of car- 
rier waves transporting the information. 

Server 1 02 can send messages and receive data, 
including program code, through network 110, and net- 
work line 112. In the Internet example, a server compu- 
ter 104 might transmit a requested code for an applica- 
tion program through the Internet using network 110 to 
server computer 102. In accord with the invention: one 
such downloaded application is Method and System for 
S Ecu re Distribution of Cryptographic Keys on Multicast 
Networks and described herein. The received code can 
be executed by server computer 102 as it is received, 
and/or stored in a storage device for later execution. In 
this manner, server computer 1 02 can obtain application 
code in the form of a carrier wave. 

Typically, processor 1 1 4 on server 1 02 fetches com- 
puter instructions from primary storage 116 through I/O 
interface 120. After retrieving these instructions, proc- 
essor 1 1 4 executes these the computer instructions. Ex- 
ecuting these computer instructions enables the proc- 
essor 114 to retrieve data or write data to primary stor- 
age 116, secondary storage 118, display information on 
one or more computer display devices (not shown), re- 
ceive command signals from one or more input devices 
(not shown), or retrieve data or write data to other com- 
puter systems coupled to network 110 such as server 
104, and client 106. Those skilled in the art also under- 
stand that primary storage 116 and secondary storage 
118 can include any type of computer storage including, 
without limitation, randomly accessible memory (RAM), 
read-only-memory (ROM), magnetic storage devices 
and optical storage media such as CD-ROM. In one em- 
bodiment, processor 114 can be any ol the S PARC 
compatible processors, UltraSPARC compatible proc- 
essors or JAVA 1 compatible processors available from 
Sun Microsystems, Inc. of Mountain View, California. Al- 

1 JAVA. PicoJAVA. UltraJAVA. HoUAVA, The Network is the Computer, 
Sun. the Sun logo, Sun Microsystems, Solaris, and Ultra are trademarks 
or registered trademarks of Sun Microsystems, Inc. in the United States 
and in other countries. All SPARC trademarks are used under license 
and are trademarks or registered trademarks of SPARC International. 
Inc. in the United States and other countries. Products bearing SPARC 
trademarks are based upon an architecture developed by Sun Micro- 
systems. Inc. UNIX is a registered trademark in the United States and 
other countries exclusively licensed through X/Open Company. Ltd. 
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tentatively, processor 114 can be based on the Power- 
PC processor available from Motorola of Schaumburg, 
I llinois, or any of the Pentium or x86 compatible proces- 
sors available from the Intel Corporation or other corpo- 
rations such as AMD, and Cyrix. 

Primary storage 116 includes an operating system 
122 for managing computer resources. Preferably, this 
operating system is the Solaris operating system or any 
operating system with support for object oriented pro- 
gramming languages such as the JAVA programming 
language or high level programming languages such as 
C. Also included in primary storage 116 is a key distri- 
bution process 124 designed in accordance with the 
present invention and a key request process 126 also 
designed in accordance with the present invention. Em- 
bodiments ol key distribution process 124 concern the 
secure distribution ol a multicast cryptographic key from 
one or more seed nodes or one or more keyed nodes 
to one or more requesting nodes. Generally, the re- 
questing nodes are coupled to different networks on an 
internetwork and are requesting the multicast crypto- 
graphic key to participate in a multicast transmission. In 
another embodiment of the present invention, key re- 
quest process 126 generally concerns how the one or 
more requesting nodes request the multicast crypto- 
graphic key from the one or more seed nodes and the 
one or more keyed nodes. Accordingly, key distribution 
process 1 24 and key request process 1 26 work together 
in a client-server relationship as discussed in further de- 
tail below. This client-server relationship reduces traffic 
and distributes the bad associated with key manage- 
ment in a large multicast group. Those skilled in the art 
will understand that the multicast cryptographic key can 
be used as traffic keys, which encrypts multicast data 
directly, or as a key encrypting key used to encrypt traffic 
keys rather than the actual data. 

In one aspect of the present invention, key distribu- 
tion process 124 provides an improved method and ap- 
paratus for distributing a multicast cryptographic key to 
a requesting node from either a "seed" node or a "keyed" 
node. In this context, the requesting node is a node on 
the network which needs the multicast cryptographic 
key to decrypt data packets being transmitted over the 
network. The "seed" node includes any node on the net- 
work initially "seeded" with the multicast cryptographic 
key being requested. In contrast to the "seed" node, the 
"keyed" nodes are those nodes which receive the mul- 
ticast cryptographic key only after requesting the multi- 
cast cryptographic key vis a vis embodiments of the 
present invention. The seed node or keyed closest to 
the requesting node on the network provides the multi- 
cast cryptographic key to the requesting node. Details 
on seed nodes and keyed nodes are discussed in f u rther 
detail below. 

Referring to FIG. 2, a flowchart indicates the overall 
steps used by one embodiment of the present invention 
to distribute a multicast cryptographic key from either a 
seed node or a keyed node to a requesting node . Ini- 



tially, step 202 establishes the seed nodes on the net- 
work when a multicast group is created. Seed nodes in- 
itially receive the multicast cryptographic key before the 
other members of the multicast group. Typically one 
5 seed node is used if the size of the multicast group is 
small and restricted to a small geographic area. Multiple 
seed nodes are generally used if the multicast group is 
targe and spread out over a large geographic area. For 
example, if the group membership spans a wide geog- 
10 raphy, multiple seed members are strategically placed 
close to large subsets of the multicast group members. 
Consequently, a multicast group including members in 
eastern Europe and the western United States would 
have multiple seed members placed in various locations 
is in eastern Europe and the western United States to im- 
prove the key distribution process. 

At step 204 one of the seed nodes established in 
step 202 receives a multicast transmission for a multi- 
cast cryptographic key from a requesting node. Typical- 
20 |y, the multicast request is made using an insecure 
transmission technique over a well known port on the 
network. The insecure multicast request is generally 
processed move quickly and efficiently than a secure 
request because the insecure request is neither auth en - 
2S ticatcd nor encrypted. As will be apparent from the dis- 
cussion below, using insecure request at this stage does 
not compromise the security of the overall key distribu- 
tion technique. 

Next, processing transfers from step 204 to deter- 
30 mination step 206 where the seed node determines if 
the requesting node has permission to receive the mul- 
ticast cryptographic key The purpose of this step is to 
limit the access to multicast transmission to only the 
members of the multicast group. Initially, the seed node 
compares the requesting node's identity with an authen- 
ticated predetermined list of nodes having permission 
to receive the requested multicast cryptographic key If 
the comparison indicates the requesting node is not 
member of multicast group, processing transfers from 
step 206 to step 208 where the seed node denies the 
multicast request. However, if the comparison indicates 
that the requesting node is a member of the predeter- 
mined list of nodes, processing will transfer from step 
206 to step 210 where the seed node responds to the 
multicast request for the multicast cryptographic key. In 
one embodiment, the authenticated predetermined list 
of nodes is an access control list or ACL. Typically, the 
ACL is authenticated using a digital signature and dis- 
tributed to each member of the multicast group prior to 
the multicast transmission using techniques well known 
to those skilled in the art. The ACL includes all the nodes 
approved for inclusion in the secure multicast transmis- 
sion. 

Assuming the requesting node is on the authenti- 
cated predetermined list of nodes, processing transfers 
from step 206 to step 21 0 where the seed node transfers 
the multicast cryptographic key over the network to the 
requesting node using a secure unicast key manage- 
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ment technique such as unicast SKIP. Unicast SKIP us- 
es public key key-distribution techniques. Public key 
key-distribution is advantageous because keys can be 
distributed quickly, efficiently, and securely over an in- 
ternetwork. For example, a seed node using unicast 
SKIP has a private key /and a certified public key g' mod 
p. Similarly, the particular requesting node has a private 
key /and a certified public key gimod p. Both of the public 
keys are available to the public from a certified distrib- 
utor in the form of a public key certificate. The seed node 
and requesting node pair can then calculate a mutually 
shared secret g'i mod p using the well known Diffie-Hell- 
man algorithm. Specifically, the seed node and the re- 
questing node calculate the shared secret based on 
knowledge of the other's identify and the corresponding 
public key certificate. Consequently, the actual shared 
secret does not need to be explicitly communicated to 
either the seed node or the requesting node over the 
internetwork. 

The mutually shared secret g'i mod p is used to de- 
rive a first cryptographic key, which is denoted Kjj. Ini- 
tially, the seed node derives this first cryptographic key 
by taking the low-order bits of g'i mod p corresponding 
to the predetermined bit size of the third key. The seed 
nodes computes and uses the first key as a master 
or key-encrypting key to encrypt a second cryptographic 
key. The second cryptographic key is a key -encrypting 
key ancfis used to encrypt the multicast encryption key. 
The multicast encryption key is the group interchange 
key or GIK used to encrypt multicast data transmitted 
over the' network. The seed node sends the requesting 
node arVencrypted unicast packet generated using the 
two step' encryption procedure discussed above. FIG. 4 
illustrates one embodiment of an encrypted unicast 
packet^generated for securely transmitting a GIK. In 
SKIP, the second cryptographic key and the multicast 
cryptographic key are distirbuted in the packet transmit- 
ted over the internetwork between the seed node and 
the requesting node. Unicast packet illustrated in FIG. 
4 includes a second cryptographic key 404 encrypted 
using a first key K^ 402 derived using a public key, a 
multicast cryptographic key or group interchange key 
406 encrypted using second cryptographic key 404, and 
a clear header 408 utilized to route the unicast packet 
over the internetwork. 

The requesting node receives the unicast packet 
and computes the first cryptographic key K V) in a similar 
manner lo the seed node and decrypts the second cryp- 
tographic key. The requesting node then uses the sec- 
ond cryptographic key to decrypt the data packet and 
isolate the multicast cryptographic key for use later in 
the multicast transmission. It should be understood if an 
imposter poses as the requesting node, tho socond key 
and the multicast cryptographic key remain secure. The 
imposter requesting node can obtain the unicast data 
packet but will not have the correct private key associ- 
ated with the true requesting node. This will prevent the 
imposter node from computing the shared secret value, 



deriving the first cryptographic key, decrypting the sec- 
ond cryptographic key, and consequently obtaining the 
multicast cryptographic key. Details on the use of secure 
unicast SKIP are included in U.S. Patent Serial Number 
s 5,548,646 entitled "System for Signatureless Transmis- 
sion and Reception of Data Packets Between Compuer 
Networks", authored by Ashar Aziz and Geoffrey Mulli- 
gan, assigned to the assigned of the present invention 
and herein incorporated by referenced in the entirety 
10 As previously discussed, a second portion of the 
present invention includes key request process 126 
(FIG. 1). Accordingly, a requesting nodes uses key re- 
quest process 1 26 to request the multicast cryptograph- 
ic key, such as a group interchange key or GIK, from the 
is one or more seed nodes and the one or more keyed 
nodes coupled to the internetwork. As will be apparent 
from the discussion below, a requesting node using key 
request process 1 26 will obtain a multicast cryptograph- 
ic key from the keyed node or seed node closest to the 
requesting node at the time of the request. Compared 
with other nodes on the network, the closest seed node 
or keyed node can send a packet to the requesting node 
which traverses the least number of networks and thus 
uses the fewest number of hops. 

Referring to FIG. 3, a flow chart outlines the overall 
steps used by one embodiment of the present invention 
to obtain the multicast cryptographic key. Initially, at step 
302, the requesting node generates a multicast request 
for a multicast cryptographic key. The multicast request 
is transmitted over the internetwork and addressed to a 
special multicast address the seed nodes and keyed 
nodes are monitoring. It is important to note that the mul- 
ticast request can be both unencrypted and unauthen- 
ticated without compromising overall security of the mul- 
ticast key distribution process. Essentially, the seed 
nodes and keyed nodes receiving the request need only 
verify the requesting node is an authorized node based 
on the authorized control lists (ACL) because the re- 
sponse is encrypted in a manner only the real requesting 
node will be able to decrypt. An imposter node attempt- 
ing "a man in the middle" or other similar cryptographic 
attacks can act as an authorized requesting node but 
can not decrypt the response which has been encrypted 
using a secure unicast transmission such as SKIP This 
unique aspect of the present invention reduces the com- 
plexity associated with key management without com- 
promising the level of security. 

Next, at step 304, the requesting node transmits the 
multicast request a predetermined number of hops over 
the internetwork to nearby seed nodes and keyed nodes 
using an expanding multicast ring. The expanding mul- 
ticast ring can be viewed as a series of messages trans- 
mitted over the internetwork using an increasing hop 
count. Those skilled in the art will understand that a hop 
is defined as the distance between two networks cou- 
pled together by a router, a switch, abridge or other net- 
work connectivity device. Accordingly, each time a mes- 
sage travels between two networks, the network con- 
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nectivity device decrements the hop count. Thus, the 
hop count measures how many networks away from the 
requesting node a message has travelled. Over time, 
the expanding multicast ring will send requests further 
out over the network looking for a seed nor or keyed 
node which has the multicast cryptographic key. The ex- 
panding multicast ring locates the closest seed nor or 
keyed node rather than requesting a key from a centrally 
located node which may be geographically distant As 
will become apparent from the following steps, the ex- 
panding multicast ring distributes the load associated 
with the key-management process. 

At step 306, the requesting node waits a predeter- 
mined time period for at least one response from either 
a seed node or a keyed node. Next, determination step 
308 determines if at least one response has been pro- 
vided within the predetermined time period. If no re- 
sponse has been received, the expanding multicast ring 
was not large enough to locate a seed node or keyed 
node. Thus, processing transfers to step 310 where the 
hop count is increased a predetermined hop count in- 
crement suitable under the circumstances. The appli- 
cant contemplates that various well known mathemati- 
cal number sequences such as cardinal, prime, fibon- 
acci and other mathematical relations could be used for 
this predetermined hop count increment. For example, 
the hop count sequence used in one expanding multi- 
cast ring could be an exponential sequence such as 1, 
2, 4, 8, 16, ... n 2 This hop count sequence would ex- 
pand the multicastring quickly and therefore locate the 
multicast cryptographic key quickly. 

After increasing the hop count an appropriate 
number of times and performing steps 304-31 0 iterative- 
ly, the requesting node eventually receives a secure uni- 
cast transmission, including the multicast cryptographic 
key, from either a seed node or a keyed node coupled 
to the internetwork. If unicast SKIP is used, the multicast 
cryptographic key is encrypted using the two step en- 
cryption process discussed above. Accordingly, 
processing transfers from step 308 to step 312 where 
the destination node proceeds to decrypt the secure uni- 
cast transmission to obtain the multicast cryptographic 
key value. 

At step 314 in FIG. 3 the receiving node determines 
if the multicast cryptographic key is authenticate or has 
been falsified by an imposter. Authentication can be 
done using several different techniques. One technique 
authenticates that the multicast cryptographic key is 
from a member of the multicast group using an access 
control list or ACL. This ACL is typically authenticated 
and distributed some time before the multicast transmis- 
sion and contains all the members in the multicast group 
and, ifthoy exist, includes any seed members and keyed 
members. Another authentication technique relies on 
the secure unicast response containing the multicast 
cryptographic key encrypted using public key encryption 
techniques such as the one described in unicast SKIP. 
Another technique authenticates the multicast crypto- 



graphic key by a digital signature on the multicast cryp- 
tographic key This digital signature may be time- 
stamped in order to prevent old digitally signed group 
keys from being re-used by an imposter seed node. 
5 Those skilled in the art will understand how a multicast 
cryptographic key is signed and authenticated in the 
manner discussed above. 

After authenticating the multicast cryptographic 
key, processing transfers to step 31 6 which converts the 
io requesting node into a keyed node capable of distribut- 
ing the multicast cryptographic key using similar tech- 
niques discussed above for the seed nodes. This ena- 
bles the requesting node to distribute the cryptographic 
key to subsequent requesting nodes on the internetwork 
is which are members of the multicast group and need the 
multicast cryptographic key Thus, the seed node and 
the keyed nodes are functionally equivalent with respect 
to key distribution execpt that the seed node receives 
the multicast cryptographic key upon multicast group 
20 creation and the keyed node receives the multicast cryp- 
tographic key only after requesting and successfully re- 
ceiving the multicast cryptographic key. Both the keyed 
node and the seed node are able to distribute the mul- 
ticast cryptographic key over the internetwork. In one 
25 embodiment, the requesting node converts itself into a 
keyed node by invoking a process which allows the re- 
questing node to distribute the multicast cryptographic 
key in the same manner as the seed nodes discussed 
above. In an alternative embodiment, a seed node can 
30 convert a requesting node into a keyed node capable of 
distributing the multicast cryptographic key. In this alter- 
native embodiment: the seed node transfers key distri- 
bution software onto the requesting node and config- 
ures key distribution software to perform the same key 
35 distribution techniques performed by the seed node for 
distributing the multicast cryptographic key. 

Embodiments of the invention offer several advan- 
tages in the area of key management for use in encryp- 
tion systems which were previously unavailable in the 
40 art. Unlike existing techniques, this key management 
system scales well in a large multicasting network with 
members spread out over a large geographic distance. 
In the past, a single group coordinator (GC) would be- 
come quickly overwhelmed if all the members in a mul- 
<5 ticast group requested an encryption key in a short time 
interval. For example, the multicast SKIP protocol used 
a single GC to distribute the multicast cryptographic key, 
called Ihe group interchange key (GIK), to each member 
of the multicast group who wanted to receive multicast 
50 transmissions. This worked well, for small multicast 
groups but did not scale well for larger multicast groups. 
By enhanching SKIP with teachings of the present in- 
vention, the processing associated with distributing the 
key is spread out to multiple seed nodes and keyed 
55 nodes on the internetwork. This technique minimizes 
the demand on a central GC because members of the 
multicast group can request a GIK from the nearest 
keyed node or seed node rather than one centrally lo- 
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cated GC. The expanding ring of multicast requests fur- 
ther exploits the availability of cryptographic keys on 
multiple seed nodes and keyed nodes on a network by 
making requests for the multicast cryptographic key 
from the closest seed nodes and keyed nodes. 

The techniques used by the present invention are 
also beneficial because they balance the processing 
load associated with key distribution based on the geo- 
graphic location of key requests. Each additional cryp- 
tographic key request establishes a keyed node which 
can distribute the cryptographic key to other nearby 
nodes on the internetwork. Using multiple seed nodes 
and keyed nodes to distribute the multicast cryptograph- 
ic key distributes the processing load to many different 
nodes rather than one group controlloer or GC. 

Further, requesting a cryptographic key using an 
expanding ring locates nearby seed nodes or keyed 
nodes rather than a distant node on the network. This 
minimizes network traffic and makes key distribution 
fast and elficienl. Consequently, members in a large 
multicast group will experience consistent key distribu- 
tion performance when requesting cryptographic keys 
even if they are located in different geographic locations. 

While specific embodiments have been described 
herein for purposes of illustration, various modifications 
may be made without departing from the spirit and 
scope of the invention. Generally, embodiments of the 
presentNnvention provide a technique for dynamically 
balancing the load associated with distributing a group 
key. Thus, those skilled in the art will understand that 
embodiments of the present invention are not limited to 
work secure unicastSKIP but can work with any number 
of secure unicast key distribution techniques. Those 
skilled iri the art will also understand that the present 
invention can be implemented using a variety of different 
networking protocols and is not limited to computer sys- 
tems coupled to a network using the TCPIP protocol 
Alternative embodiments substantially similar to the pre- 
ferred embodiment could be implemented except that 
the network protocol would be SNA, Appletalk", IPX, X. 
25, SLI P, or PPP. Those skilled in the art understand that 
computer systems running TCP/IP can also communi- 
cate with other computer systems running other diverse 
network protocols such as SNA (Systems Network Ar- 
chitecture), IPX, Appletalk, or X.25. For more informa- 
tion on integrating TCP/IP and SNA networks see Inte- 
grating TCP/IP Into SNA , Taylor, Wordware Publishers, 
1993. 

Accordingly, the invention is not limited to the above 
described embodiments, but instead is defined by the 
appended claims in light of their full scope of equiva- 
lents. 



Claims 

1 . A method executed on one or more seed nodes and 
one or more keyed nodes for securely distributing 
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a cryptographic key, initially located on the one or 
more seed nodes, to a requesting node wherein the 
one or more seed nodes, the one or more keyed 
nodes, and the requesting node are each coupled 
5 to one or more networks in an internetwork, the 
method comprising the steps of: 

receiving a multicast transmission request for 
the cryptographic key from the requesting 
10 node; 

encrypting the cryptographic key; and 
transferring the encrypted cryptographic key to 
the requesting node with a secure unicast 
transmission. 

15 

2. The method of Claim 1 wherein the receiving step 
further comprises the steps of: 

determining if the requesting node making the 
multicast request has permission to receive the 
20 cryptographic key by performing the following 
steps, 

comparing the identity of the requesting node 
with an authenticated list of nodes having per- 
25 mission to receive the cryptographic key; and 

responding to the multicast request if the com- 
paring step indicates the requesting node is a 
member of the list of nodes having permission 
to receive the cryptographic key. 

30 

3. The method of Claim 1 further comprising the step 
of converting the requesting node into a keyed node 
by configuring the requesting node to perform a 
method comprising the following steps of: 

35 

receiving a multicast transmission request for 
the cryptographic key from a subsequent re- 
questing node; 

encrypting the cryptographic key; and 
40 transferring the encrypted cryptographic key to 

the subsequent requesting node with a secure 
unicast transmission. 

4. The method of Claim 1 wherein the cryptographic 
45 key is requested by the requesting node to decrypt 

data being transmitted over a secure multicast 
transmission between members of a multicast 
group. 

so 5. The method of Claim 1 further including the step of 
including the one or more seed nodes, the one or 
more keyed nodes, and the requesting nodes as 
members of a multicast group. 

ss 6. The method of Claim 5 further including the step of 
distributing the one or more seed nodes over the 
internetwork to minimize the distance over the in- 
ternetwork between each member of the multicast 
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group on the internetwork and a seed node or a 
keyed node on the internetwork. 

7. The method of Claim 1 wherein the multicast re- 
quest made by the requesting node to the seed 
node is neither authenticated nor encrypted. 

8. The method of Claim 1 wherein the secure unicast 
transmission is performed using unicast SKIP 

9. A method executed on a requesting node coupled 
to a network on an internetwork for obtaining a cryp- 
tographic key from one or more seed nodes andone 
or more keyed nodes coupled to one more different 
networks on the internetwork, wherein each of the 
one or more seed nodes and the one or more keyed 
nodes are capable of transmitting the cryptographic 
key to the requesting node, the method comprising 
the steps of: 

generating a multicast request for the crypto- 
graphic key; 

transmitting the multicast request for the cryp- 
tographic key a predetermined number of hops 
over the internetwork directed to the one or 
more seed nodes and the one or more keyed 
nodes coupled to the internetwork; 
waiting for at least one response from at least 
one seed node or keyed node coupled to the 
network; and 

when the at least one response is not received 
within a time period, increasing the hop count 
by a hop count increment and repeating the 
above steps of generating a multicast request, 
transmitting the multicast request, and delaying 
a time period. 

10. The method of Claim 9 further including the step of 
iteratively performing the steps of generating a mul- 
ticast request, transmitting the multicast request, 
delaying a time period, and increasing the hop 
count until the at least one response is received 
within the time period. 



obtain the cryptographic key; and 
converting the requesting node into a keyed 
node capable of providing the cryptographic 
key to other requesting nodes located on the 
5 internetwork. 

13. The method of Claim 9 wherein the cryptographic 
key is requested by the requesting node to decrypt 
data being transmitted over a secure multicast 

1° transmission between members of a multicast 
group. 

14. The method of Claim 9 wherein the multicast re- 
quest made by the requesting node to the one or 

15 more seed nodes and the one or more keyed nodes 
is neither authenticated nor encrypted. 



20 



15. The method of Claim 1 2 wherein the secure unicast 
transmission is performed using unicast SKIP. 



1 6. An apparatus embedded in one or more seed nodes 
and one or more keyed nodes which securely dis- 
tributes a cryptographic key, initially located on the 
one or more seed nodes, to a requesting node 
25 wherein the one or more seed nodes, the one or 
more keyed nodes, and the requesting node are 
each, coupled to one or more networks in an inter- 
network, the apparatus comprising: 
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a mechanism configured to receive a multicast 
transmission request for the cryptographic key 
from the requesting node: 
a mechanism configured to encrypt the crypto- 
graphic key; and 

a mechanism configured to transfer the en- 
crypted cryptographic key to the requesting 
node with a secure unicast transmission. 



11. The method of Claim 10 wherein the hop count in- 
crement is increased exponentially with each itera- 
tion. 

12. The method of Claim 9, further comprising, subse- 
quent to the step of increasing the hop count, the 
steps of: 

receiving the at least one response within the 
time period in the form of a secure unicast 
transmission from at least one seed node or 
keyed node which includes the cryptographic 
key; 

decrypting the secure unicast transmission to 



17. The apparatus of Claim 16 wherein the mechanism 
40 configured to receive is further comprised of: 

a mechanism configured to determine if the re- 
questing node making the multicast request 
has permission to receive the cryptographic 
key by performing the following steps, 
a mechanism configured to compare the iden- 
tity of the requesting node with an authenticat- 
ed predetermined list of nodes having permis- 
sion to receive the cryptographic key; and 
a mechanism configured to respond to the mul- 
ticast request if the comparing mechanism in- 
dicates the requesting node is a member of the 
predetermined list of nodes having permission 
to receive the cryptographic key. 
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18. The apparatus of Claim 17, having a mechanism to 
convert the requesting node into a keyed node ca- 
pable of distributing the cryptographic key to a sub- 
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sequent requesting node, further comprising: 

a mechanism configured to receive a multicast 
transmission request for the cryptographic key 
from a subsequent requesting node; 
a mechanism configured to encrypt the crypto- 
graphic key; and 

a mechanism configured to transfer the en- 
crypted cryptographic key to the subsequent 
requesting node with a secure unicast trans- 
mission. 

19. The apparatus of Claim 16 wherein the crypto- 
graphic key is requested by the requesting node to 
decrypt data being transmitted over a secure multi- 
cast transmission between members of a multicast 
group. 

20. The apparatus of Claim 16 further including the step 
of including the one or more seed nodes, Ihe one 
or more keyed nodes, and the requesting nodes as 
members of a multicast group. 

21. The apparatus of Claim 16 further including an ap- 
paratus configured to distribute the one or more 
seed nodes over the internetwork to minimize the 
distance over the internetwork between each mem- 
ber^ the multicast group on the internetwork and 
a seed node or a keyed node on the internetwork. 

22. Theiapparatus of Claim 1 6 wherein the multicast re- 
quest made from the requesting node to the seed 
node is neither authenticated nor encrypted. 

23. The apparatus of Claim 16 wherein the secure uni- 
cast transmission is performed using unicast SKIP. 

24. An apparatus embedded in a requesting node cou- 
pled to a network on an internetwork configured to 
obtain a cryptographic key from one or more seed 
nodes and one or more keyed nodes coupled to one 
more different networks on the internetwork, where- 
in each of the one or more seed nodes and the one 
or more keyed nodes are capable of transmitting the 
cryptographic key to the requesting node, the ap- 
paratus comprising: 

a mechanism configured to generate a multi- 
cast request for the cryptographic key; 
a mechanism configured to transmit the multi- 
cast request for the cryptographic key a prede- 
termined number of hops over the internetwork 
directed to the one or more seed nodes and the 
one or more keyed nodes coupled to the inter- 
network; 

a mechanism configured to delay a time period 
for at least one response from at least one seed 
node or keyed node coupled to the network; 



and 

a mechanism configured to increase the hop 
count by a hop count increment when the at 
least one response is not received within the 
5 time period. 

25. The apparatus of Claim 24 wherein the mechanism 
configured to increase the hop count increases the 
hop count increment exponentially each time it is 

10 operated. 

26. The apparatus of Claim 24, further comprising: 

a mechanism configured to receive the at least 
15 one response, within the time period, in the 

form of a secure unicast transmission from at 
least one seed node or keyed node which in- 
cludes the cryptographic key; 
a mechanism configured to decrypt the secure 
20 unicast transmission to obtain the cryptograph- 

ic key; and 

a mechanism configured to convert the re- 
questing node into a keyed node capable of 
providing the cryptographic key to other re- 
25 questing nodes located on the internetwork. 

27. The apparatus of Claim 24 wherein the crypto- 
graphic key is requested by the requesting node to 
decrypt data being transmitted over a secure multi- 

30 cast transmission between members of a multicast 
group. 

28. The apparatus of Claim 24 wherein the multicast re- 
quest made by the requesting node to the one or 

35 more seed nodes and the on e or more keyed nodes 
is neither authenticated nor encrypted. 

29. The apparatus of Claim 24 wherein the secure uni- 
cast transmission is performed using unicast SKIP 
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30. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, 
when executed by a processor, causes one or more 
seed nodes and one or more keyed nodes in to se- 
curely distribute a cryptographic key, initially locat- 
ed on the one or more seed nodes, to a requesting 
node wherein the one or more seed nodes, the one 
or more keyed nodes, and the requesting node are 
each coupled to one or more networks in an inter- 
network, by performing the following steps of: 

receiving a multicast transmission request for 
the cryptographic key from the requesting 
node; 

encrypting the cryptographic key; and 
transferring the encrypted cryptographic key to 
the requesting node with a secure unicast 
transmission. 
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31. The data signal embodied in a carrier wave of Claim 
30 wherein the receiving step further comprises the 
steps of: 

determining if the requesting node making the 
multicast request has permission to receive the s 
cryptographic key by performing the following 
steps, 

comparing the identity of the requesting node 
with an authenticated list of nodes having per- 10 
mission to receive the cryptographic key; and 
responding to the multicast request if the com- 
paring step indicates the requesting node is a 
member of the list of nodes having permission 
to receive the cryptographic key. is 

32. The data signal embodied in a carrier wave of Claim 
30 further comprising the step of converting the re- 
questing node into a keyed node by configuring the 
requesting node to perform a method comprising 20 
the following steps of: 

receiving a multicast transmission request for 
the cryptographic key from a subsequent re- 
questing node; 2s 
encrypting the cryptographic key; and 
transferring the encrypted cryptographic key to 
the subsequent requesting node with a secure 
unicast transmission. 

30 

33. The data signal embodied in a carrier wave of Claim 
30 wherein the cryptographic key is requested by 
the requesting node to decrypt data being transmit- 
ted over a secure multicast transmission between 
members of a multicast group. 35 



34. The data signal embodied in a carrier wave of Claim 
30 further including the step of including the one or 
more seed nodes, the one or more keyed nodes, 
and the requesting nodes as members of a multi- 
cast group. 

35. The data signal embodied in a carrier wave of Claim 
34 further including the step of distributing the one 
or more seed nodes over the internetwork to mini- 
mize the distance over the internetwork between 
each member of the multicast group on the internet- 
work and a seed node or a keyed node on the in- 
ternetwork. 

36. The data signal embodied in a carrier wave of Claim 
30 wherein the multicast request made by the re- 
questing node to the sood node is neither authenti- 
cated nor encrypted. 

37. The data signal embodied in a carrier wave of Claim 
30 wherein the secure unicast transmission is per- 
formed using unicast SKIP. 
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38. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, 
when executed by a processor, causes a requesting 
node coupled to a network on an internetwork to ob- 
tain a cryptographic key from one or more seed 
nodes and one or more keyed nodes coupled to one 
more different networks on the internetwork, where- 
in each of the one or more seed nodes and the one 
or more keyed nodes are capable of transmitting the 
cryptographic key to the requesting node, by per- 
forming the following steps of: 

generating a multicast request for the crypto- 
graphic key; 

transmitting the multicast request for the cryp- 
tographic key a predetermined number of hops 
over the internetwork directed to the one or 
more seed nodes and the one or more keyed 
nodes coupled to the internetwork; 
wailing for at least one response from at least 
one seed node or keyed node coupled to the 
network; and 

when the at least one response is not received 
within a time period : increasing the hop count 
by a hop count increment and repeating the 
above steps of generating a multicast request, 
transmitting the multicast request, and delaying 
a time period. 

39. The method of Claim 38 further including the step 
of iteratively performing the steps of generating a 
multicast request, transmitting the multicast re- 
quest, delaying a time period, and increasing the 
hop count until the at least one response is received 
within the time period. 

40. The computer data signal embodied in a carrier 
wave of Claim 39 wherein the hop count increment 
is increased exponentially with each iteration. 

41. The computer data signal embodied in a carrier 
wave of Claim 38, further comprising, subsequent 
to the step of increasing the hop count, the steps of: 

receiving the at least one response within the 
time period in the form of a secure unicast 
transmission from at least one seed node or 
keyed node which includes the cryptographic 
key; 

decrypting the secure unicast transmission to 
obtain the cryptographic key; and 
converting the requesting node into a keyed 
node capable of providing the cryptographic 
key to other requesting nodes located on the 
internetwork. 

42. The computer data signal embodied in a carrier 
wave of Claim 38 wherein the cryptographic key is 
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requested by the requesting node to decrypt data 
being transmitted over a secure multicast transmis- 
sion between members of a multicast group. 

43. The computer data signal embodied in a carrier 
wave of Claim 38 wherein the multicast request 
made by the requesting node to the one or more 
seed nodes and the one or more keyed nodes is 
neither authenticated nor encrypted. 

44. The computer data signal embodied in a carrier 
wave of Claim 41 wherein the secure unicast trans- 
mission is performed using unicast SKIP. 
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(54) Method and system for secure distribution of cryptographic keys on multicast networks 



(57) A method and apparatus for secure and scala- 
ble key management in a multicast network environ- 
ment is provided. In a first portion, one or more seed 
nodes on the network receive a multicast transmission 
request for a cryptographic key from a requesting node. 
The seed node compares the identity of the requesting 
node with an authenticated predetermined list of nodes 
having permission to receive the cryptographic key If 
the comparison indicates the requesting node is not a 
member of the authenticated predetermined list, the 
seed node denies the multicast request. However, if the 
comparison indicates that the requesting node is a 
member of the predetermined fist of nodes, the crypto- 
graphic key is transmitted using a secure unicast key 
distribution technique such as SKIP. A second portion 
concerns the requesting node which generates a multi- 
cast request to obtain the cryptographic key from one 



or more seed nodes and one or more keyed nodes on 
the internetwork. The multicast request for the crypto- 
graphic key is initially transmitted a minimum hop count 
over the internetwork to locate the closest seed node. 
The requesting node delays a brief time period waiting 
for at least one response from at least one seed node 
or keyed node on the internetwork. If the at least one 
response is not received within this time period, the min- 
imum hop count is increased by a hop count increment 
and the requesting node repeats the above steps. Even- 
tually, the requesting node increases the hop count and 
receives the cryptographic key over a secure unicast 
key management technique such as SKIP. As a final 
step, the requesting node is convered into a keyed node. 
The keyed node acts as a seed node and provides the 
cryptographic key to other requesting nodes on the in- 
ternetwork. 
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